home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000582_dsr@hplb.hpl.hp.com _Tue Jan 19 11:58:23 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  4KB
  1. Return-Path: <dsr@hplb.hpl.hp.com>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA18806; Tue, 19 Jan 93 11:58:23 MET
  4. Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA23318; Tue, 19 Jan 1993 12:13:43 +0100
  6. Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Tue, 19 Jan 93 11:10:20 GMT
  7. Received: by manuel.hpl.hp.com
  8.     (16.6/15.6+ISC) id AA03925; Tue, 19 Jan 93 11:14:56 GMT
  9. From: Dave_Raggett <dsr@hplb.hpl.hp.com>
  10. Message-Id: <9301191114.AA03925@manuel.hpl.hp.com>
  11. Subject: HTML and Lists
  12. To: www-talk@nxoc01.cern.ch
  13. Date: Tue, 19 Jan 93 11:14:54 GMT
  14. Mailer: Elm [revision: 66.25]
  15.  
  16. DL, UL and OL Lists
  17. -------------------
  18.  
  19. Can we please avoid too tight a definition:
  20.  
  21. (from From: Dan Connolly  Thu, 14 Jan 93 to  www-talk)
  22.  
  23. > Can we do the following instead of using paragraphs in DL?
  24. > 
  25. > <DL>
  26. > <DT>large
  27. > <DT>big
  28. > <DD>Large and big are synonyms.
  29. > <DD>They share a definition.
  30. > <DD>This is the third paragraph of explanation about big
  31. > and large things.
  32. > </DL>
  33. > 
  34. > It appears that the linemode browser generally groks. Thus, let's
  35. > not mess with P's in DL's. (P's in UL's are messy enough to leave
  36. > out too, I guess.)
  37.  
  38. I support:
  39.  
  40.     o   DD terms can include <P> breaks
  41.  
  42.     o   LI terms can include <P> breaks for UL and OL lists
  43.  
  44. The use of <P> in lists is both natural and easy to implement, and I for one
  45. would find the repeated DD's awkward to deal with as well as screwing up the
  46. natural semantics of a one to one relationship between DT and DD text.
  47.  
  48.     o   DT terms can be arbitrarily long and are wrapped onto the line below
  49.  
  50. This occasionally happens, e.g. when people place long anchors as DT terms.
  51. It was also reasonably simple to implement.
  52.  
  53. It might be an improvement to emulate the approach used by Latex as in:
  54.  
  55. \begin{description}
  56.     \item[TERMS ARE IN A BIG FONT]
  57.         while their defintions follow in the normal font
  58.         and wrap round with a margin indent.
  59. \end{description}
  60.  
  61. giving:
  62.  
  63.   TERMS ARE IN A BIG FONT while their definitions follow in the normal font
  64.     and wrap round with a margin indent.
  65.  
  66. versus the HTML guidelines which suggest:
  67.  
  68.   TERMS ARE IN A BIG FONT       while their defintions follow in the normal
  69.                                 font and wrap round with a margin indent.
  70.  
  71. The Latex approach allows terms to be as long as you like, and avoids the
  72. issue of what to do when terms collide with the definition text. Perhaps
  73. the HTML guidelines should leave this issue open ...
  74.  
  75. I would further like to have the freedom to embed lists, e.g. OL in UL and
  76. vice versa, but allowing only one level of embedding, e.g.
  77.  
  78. <UL>
  79.     <LI>This is a simple item.
  80.     <LI>While this one requires some amplification:
  81.         <OL>
  82.             <LI>first point
  83.             <LI>second point
  84.             <LI>third point
  85.         </OL>
  86.     <LI>Another simple item
  87. </UL>
  88.  
  89. My implementation of lists is fairly relaxed whilst being able to support
  90. smooth scrolling of arbitrary length HTML documents. The processing demands
  91. for this require the browser to be able parse backwards - working forwards
  92. from the start of the document each time is MUCH TOO SLOW. This is not a
  93. problem unless there is an HTML feature which forces you to go back
  94. arbitrarily far before you can figure out the state (margins, font, active
  95. tags etc.) from which to work forwards again to your current location.
  96.  
  97. The awkward features turn out to be:
  98.  
  99.     a)  ordered lists
  100.     b)  multi-line DT terms
  101.  
  102. In practice neither of these has caused real problems since actual documents
  103. keep their use to relatively short sections at a time. A way out of my
  104. problems would be to embed state info in the buffer as processing attributes,
  105. so far I have been able to provide good scrolling performance while keeping to
  106. the vanilla text representation of HTML docs.
  107.  
  108. Cheers for now (the Pub is bekoning)
  109.  
  110. Dave Raggett